@trisch-me I am surprised by this new requirement that you mentioned:

We can’t have both x.y and x.y.z names as declaring x.y.z makes x.y automatically a namespace. so you can’t use it as leaf node. In our case we have originally hw.battery.charge and hw.battery.charge.limit. I have changed the latter to the hw.battery.charge_limit but I’m not sure if this is a correct way and if it breaks anything?

My opinion is that it's a shame that this limitation is caused by our tooling only. OTLP itself totally supports having hw.battery.charge and hw.battery.charge.limit.

The .limit suffix has also being used to specify thresholds, like hw.temperature.limit. Because of this limitation (namespace vs leaf), we will probably have to rename our temperature metric to hw.temperature.temperature, which is... suboptimal.

Can we add a special status for *.limit metrics, to make sure they don't create a namespace? It shouldn't be too complicated.

If not, my suggestion for battery charge and limit is to go simply with:

• hw.battery.charge (indicates the level of charge of the battery)
• hw.battery.limit (indicates the charge limits at which the battery can operate properly)

Thank you!

@trisch-me WRT "Some of the components have only hw.status. And what this actually mean - for example we do define it as hw.enclosure.* - Enclosure metrics but later say just hw.status. Should it be hw.enclosure.status", that's an excellent question!

When writing the original semconv for hardware, I tried to group metrics per component type (CPU, memory, etc.). Each component had its own status metric, like hw.enclosure.status and hw.physical_disk.status, etc. But I was asked to refactor that as simply hw.status with hw.type="enclosure|physical_disk|...", which I think was a great idea! I now strongly recommend that we keep hw.status as a generally applicable metric to any kind of hardware component. It works really great to assess hardware problems, with really simply queries.

Edit: "I WAS asked", and not "I asked" and then thought it's such a great idea 😅

Can we add a special status for *.limit metrics, to make sure they don't create a namespace? It shouldn't be too complicated.

I'm in favour of this or revisiting this whole notion of metric names and namespaces etc.; the original issue for it (#50) has been open for a while and the reasoning in favour of it doesn't seem super strong to me relative to the naming gymnastics it requires.

I have added a question about metric names to the todays semconv meeting

I wonder if we should follow the naming conventions already used by the car battery industry.
They are pretty precise and are already widely used... This could also open up OpenTelemetry to that field. See: https://en.wikipedia.org/wiki/Battery_management_system#Computation

Examples: State of charge (SoC), State of health (SoH), charge current limit(CCL)...

@thompson-tomo So there is no way we could consider .limit as a "special" metric that doesn't imply a namespace?

I am deeply skeptical of the decision that was made by the TC on this. To allow an hypothetical hierarchical representation of metrics in a JSON payload, we're now trying to invent many workarounds for this artificial limitation, with metrics like hw.voltage.actual, or hw.voltage.current (which is very very confusing).

The TC probably didn't realize the weird consequences of the decision of preventing a metric from being the prefix of another metric. A xxx.yyy metric will prevent any xxx.yyy.zzz metric further down the road, resulting in weird decisions like "let's rename xxx.yyy to xxx.yyy.current or xxx.yyy.value so that we can have xxx.yyy.zzz").

It will actually create a lot of instability in our semantic conventions!

Is there a way to "appeal" this decision? 😅

When I look at hw.voltage that sounds alot like an entity which lacks a descriptor. Does it represent the expected voltage, actual voltage, minimum voltage etc.

@bertysentry let’s discuss it today during the meeting once more, I have moved everything to the yaml files and we have no problems right now with tooling (but because we don’t check namespace re-usage for the metrics). We can raise it once more to find the appropriate solution

@bertysentry we have agreed that we merge it as is to make it pure refactoring and extracting the data from md files to the yaml files and discuss that we should come up with a solution later on how we proceed with collision
so I need you factual check if all metrics are ok and I haven’t missed anything

During todays’ semconv meeting we have discussed that we will proceed as is with current changes (not changing anything substantial) and there was a request to create a hardware SIG to discuss any other changes to this domain.

@bertysentry @thompson-tomo and everyone else interested

I have also updated github link checker to exclude removed files from check

@joaopgrassi @trask @AlexanderWert @lmolkova could you please check this PR, thanks